Execution of ADM cycles should be conducted within the project management framework of the enterprise. In some cases, architecture projects will be stand-alone. In other cases, architectural activities will be a subset of the activities within a larger project. In either case, architecture activity should be planned and managed using accepted practices for the enterprise.

Conduct the necessary (enterprise-specific) procedures to secure enterprise-wide recognition of the project, the endorsement of corporate management, and the support and commitment of the necessary line management. Include references to other management frameworks in use within the enterprise, explaining how this project relates to those frameworks.

Identify the key stakeholders and their concerns/objectives, and define the key business requirements to be addressed in the architecture engagement. Stakeholder engagement at this stage is intended to accomplish three objectives:

• To identify candidate vision components and requirements to be tested as the Architecture Vision is developed
• To identify candidate scope boundaries for the engagement to limit the extent of architectural investigation required
• To identify stakeholder concerns, issues, and cultural factors that will shape how the architecture is presented and communicated

The major product resulting from this step is a stakeholder map for the engagement, showing which stakeholders are involved with the engagement, their level of involvement, and their key concerns. The stakeholder map is used to support various outputs of the Architecture Vision phase, and to identify:

• The concerns and viewpoints that are relevant to this project; this is captured in the Architecture Vision
• The stakeholders that are involved with the project and as a result form the starting point for a Communications Plan
• The key roles and responsibilities within the project, which should be included within the Statement of Architecture Work

Another key task will be to consider which architecture views and viewpoints need to be developed to satisfy the various stakeholder requirements. As described in Part III, Stakeholder Management, understanding at this stage which stakeholders and which views need to be developed is important in setting the scope of the engagement.

Identify the business goals and strategic drivers of the organization.

If these have already been defined elsewhere within the enterprise, ensure that the existing definitions are current, and clarify any areas of ambiguity. Otherwise, go back to the originators of the Statement of Architecture Work and work with them to define these essential items and secure their endorsement by corporate management.

Define the constraints that must be dealt with, including enterprise-wide constraints and project-specific constraints (time, schedule, resources, etc.). The enterprise-wide constraints may be informed by the business and architecture principles developed in the Preliminary phase or clarified as part of Phase A.

A business capability assessment is used to define what capabilities an organization will need to fulfil its business goals and business drivers.

A business capability can be thought of as a synonym for a macro-level business function.

This step first seeks to understand the capabilities and desires of the business, then identifies options to realize those capabilities. For example, an organization may possess a finance capability and have a desire to reduce the cost of operating this capability. A suitable technique for reducing cost may be to adopt an outsourced service from a service provider. This would require the business to accept the functional limits of the packaged software, and adapt to these constraints. The business is constrained in its ability to differentiate itself in the marketplace in this functional area, should custom software be needed to support unique operations and business practices. Therefore, it is necessary for the organization to understand where it needs to differentiate itself and where a model of sufficiency at lowest cost is preferred.

Once the current and desired business capabilities are understood, their likely implications for the organization's technology capability can be assessed, creating an initial picture of new IT capability that will be required to support the Target Architecture Vision.

Showing the baseline and target capabilities within the context of the overall enterprise can be supported by creating Value Chain diagrams that show the linkage of related capabilities at the macro level, either within an individual enterprise, or across a network of related enterprises.

The results of the assessment are documented in a Capability Assessment.

A Business Transformation Readiness Assessment can be used to evaluate and quantify the organization's readiness to undergo a change. This assessment is based upon the determination and analysis/rating of a series of readiness factors, as described in Business Transformation Readiness Assessment.

The results of the readiness assessment should be added to the Capability Assessment. These results are then used to shape the scope of the architecture, to identify activities required within the architecture project, and to identify risk areas to be addressed.

Define what is inside and what is outside the scope of the Baseline Architecture and Target Architecture efforts, understanding that the baseline and target need not be described at the same level of detail. In many cases, the Baseline is described at a higher level of abstraction, so more time is available to specify the Target in sufficient detail. The issues involved in this are discussed in Scoping the Architecture. In particular, define:

• The breadth of coverage of the enterprise
• The level of detail required
• The partitioning characteristics of the architecture
• The specific architecture domains to be covered (business, data, application, technology)
• The extent of the time period aimed at, plus the number and extent of any intermediate time period
• The architectural assets to be leveraged, or considered for use, from the organization's Enterprise Continuum:
• • Assets created in previous iterations of the ADM cycle within the enterprise
  • Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.)

Based on the stakeholder concerns, business capability requirements, scope, constraints, and principles, create a high-level view of the Baseline and Target Architectures. The Architecture Vision typically covers the breadth of scope identified for the project, at a high level. Informal techniques are often employed. A common practice is to draw a simple solution concept diagram that illustrates concisely the major components of the solution and how the solution will result in benefit for the enterprise.

Business scenarios are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements. Business scenarios may also be used at more detailed levels of the architecture work (e.g., in Phase B) and are described in Part III, Business Scenarios.

This step generates the first, very high-level definitions of the baseline and target environments, from a business, information systems, and technology perspective, as described in Outputs.

These initial versions of the architecture should be stored in the Architecture Repository, organized according to the standards and guidelines established in the architecture framework.

The outputs from this activity should be incorporated within the Statement of Architecture Work to allow performance to be tracked accordingly.

Identify the risks associated with the Architecture Vision and assess the initial level of risk (e.g., catastrophic, critical, marginal, or negligible) and the potential frequency associated with it. Assign a mitigation strategy for each risk. A risk management framework is described in Part III, Risk Management.

There are two levels of risk that should be considered, namely:

• Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions.
• Residual Level of Risk: Risk categorization after implementation of mitigating actions (if any).

Risk mitigation activities should be considered for inclusion within the Statement of Architecture Work.

Assess the work products that are required to be produced (and by when) against the set of business performance requirements. This will involve ensuring that:

• Performance metrics are built into the work products.
• Specific performance-related work products are available.

Then, activities will include:

• Identify new work products that will need to be changed
• Provide direction on which existing work products, including building blocks, will need to be changed and ensure that all activities and dependencies on these are co-ordinated
• Identify the impact of change on other work products and dependence on their activities
• Based on the purpose, focus, scope, and constraints, determine which architecture domains should be developed, to what level of detail, and which architecture views should be built
• Assess the resource requirements and availability to perform the work in the timescale required; this will include adhering to the organization's planning methods and work products to produce the plans for performing a cycle of the ADM
• Estimate the resources needed, develop a roadmap and schedule for the proposed development, and document all these in the Statement of Architecture Work
• Define the performance metrics to be met during this cycle of the ADM by the enterprise architecture team
• Develop the specific enterprise architecture Communications Plan and show where, how, and when the enterprise architects will communicate with the stakeholders, including affinity groupings and communities, about the progress of the enterprise architecture developments
• Review and agree the plans with the sponsors, and secure formal approval of the Statement of Architecture Work under the appropriate governance procedures
• Gain sponsor's sign-off to proceed